Distribution of software, and specifically object code, for use in processing systems has been a problem since the beginning of stored program controlled systems. For example, in the area of telephone switching systems, stored program control has been used since the middle 1960's. In order to distribute a new operational program (software) that operates these systems, initially a technician had to go to each switching office and physically remove magnetically encoded cards and install new magnetically encoded cards. As technology improved, magnetic tapes were used to transport programs from the point at which they are made to their point of utilization; in fact, magnetic tapes are still used for generic updates which currently involve large quantities (70-100 mega-bytes (MB)) of object code. All such systems required manual steps and high transportation costs for delivery of such software, especially as the size of the software loads grew over time.
Some recent systems rely on telephone data links for distribution of software. For example, the prior art system of FIG. 4 illustrates a typical software distribution system for various switching systems in a telephone network. Such switching systems could be local central office switches supported by a particular manufacturer, such as 5ESS.RTM. switches manufactured and supported by AT&T, or, alternatively, may be long distance-type switches such as the 4ESS.TM. switch, also manufactured and supported by AT&T. Other types of program-controlled systems may benefit from this invention without departing from the scope of the appended claims.
Each switch is connected to a software change and notification system (SCANS) 102. SCANS, as known in the art, provides software updates for switching systems 104-118 by way of data transmissions over lines 120-134 using dedicated point-to-point communication links typically operating at 9600 bits per second with an X.25 protocol.
FIG. 5 illustrates such a prior art SCANS-to-switching system connection. In the system of FIG. 5, SCANS 100 includes an application program 500, which processes the data to be sent (in the example of switching offices, the object code required). Application program 500 delivers the processed object code to a plurality of communications terminal processes 502-5NN, which communicate with the switching offices. In each communications terminal process 502-5NN, there is a send module 504 and a receive module 506. Send module sends the object code (again, for purposes of this example) over line 120 to switching system 104. Receive module 506 in terminal process 502 of SCANS 100 receives acknowledgement requests for re-tries, etc., as is known in the art, from switching module 104, via line 120.
At the switching system side, switching systems (in this example 102 and 104), also include a terminal process 508-508' which contain a send module 504 and a receive module 506 which are the same, or substantially similar, to the send 504 and receive processes 506 in the communications terminal process 502 of SCANS 100. Terminal process 508 in switching system 104 receives data in receive process 506 and delivers received data to terminal process 508. Terminal process 508 determines whether the data is received in tact, and if so, sends acknowledgements of good reception through send process 504 or re-try requests for data if the data appeared to be corrupted. Switching systems 104 and 102 are shown as having several layers that communicate with communications terminal process 508. First there is a SCANS interface 510 which performs protocol verification, etc. and other functions, as known in the art, with SCANS 100. If the data received appears correct, then SCANS interface 510 passes the received data to input/output process 512, which causes administrative module 514 to further distribute the received software to where the other processes reside. This hierarchy is very much like the system of FIG. 2.
In this manner, changes to the programs which run switching systems 102-118 may be made through a central location, for example, at a SCANS facility 100 outside of Chicago, and then sent to each switching system which requires the change. Furthermore, software updates, where entire sections of programs change, may also be sent to each switch 102-118 in this manner. Finally, an entire generic update (changing the entire operating code) may be sent from SCANS 100, via lines 120-134, to all switching systems 102-118 which subscribe to or purchase the new generic. Therefore, the size of the data load being transmitted to each switch may vary from a few hundred bytes for a small bug fix to several hundred megabytes for an entire generic.
Turning now to FIG. 6, a prior art system is shown, wherein a switching office is connected to SCANS 100 by way of data line 120. Switching office 104 is, for example, a 5ESS switch, as manufactured by AT&T. As is known in the art, a 5ESS switch (local switch 104) may be a distributed control ISDN electronic telephone switching system such as the system disclosed in U.S. Pat. No. 4,592,048, issued to M. W. Beckner, et al. on May 27, 1986, and assigned to the assignee of this application. Alternatively, local switch 104 may be a digital switch such as a 5ESS switch manufactured by AT&T and described in the AT&T Technical Journal, Vol. 64, Number 6, July/August, 1995, pages 1303-1564.
The architecture of switch 104 includes a communication module 602 as a hub, with switching modules 604, 606, and 608 illustrated (there may be other switching modules but these are not shown for clarity) and an administrative module (AM) 610, emanating from communication module 602. Communication module 602 includes a time-shared, space division switch or time-multiplexed (TM) switch as a fabric for communications among switch modules 604, 606, 608, and between switch modules 604, 606 and 608 the AM 610. AM 610 provides coordination of the functional components of switch 104 and human-machine interface. Switch modules 604, 606, and 608 terminate analog and/or digital subscriber lines through line units (not shown but well-known in the art) and analog or digital trunk units (again, not shown but well known in the art) and communicates with CM 602 over control timeslots 611 (for sending control data) and other timeslots 613 (for call processing). AM 610 also provides connections to other switching systems through, for example, a signaling system 612 (such as a common channel signaling network) by which the switching systems in a network communicate, and to SCANS 100 via connection 120.
In the current art, SCANS 102 sends data on line 120 at typically 9600 baud. This data rate is adequate when SCANS 100 is sending small changes (or "patches") for code to switching office 104. However, when SCANS 100 is sending major updates or a generic update over line 120, this transmission may take many hours, depending on the size of the load or generic which is being sent to the administrative module 610. Further, because of the nature of object code being one large block, a major error in delivery requires a total restart of the system.
The burden of distributing large software loads, particularly object code, at 9600 bps to AM 610 may slow down or delay other processing work of AM 610. For example, receiving an entire generic causes AM 610 to respond more slowly to signaling messages from signaling network 612 and for routing and administrative function requests from SMs 604-608 and CM 602. Therefore, it has been proposed that AM 610 be assisted by a work station, such as 614 (shown in phantom). Work station 614 is connected to SCANS 100 (instead of AM 610) and then communicates with AM 610 to build loads and otherwise direct AM 610 with the information delivered from SCANS 100. However, there is still a great deal of time involved delivering data from SCANS 100 to work station 614; work station 614 merely eases some of the processing burden on AM 610.
Data being transmitted in any form is subject to becoming corrupt and, thus, producing errors at the receiving end. Such corruption may be caused by transients in electrical networks, atmosphere conditions, satellite broadcasts, etc. Such data errors are well known and are the basic reasons for the various protocols described in FIGS. 1, 2, and 3. However, the less preparation of the code for transmission, the more likely it is for the code to become corrupt during transmission and not recoverable at the far end. Various methods have been described in the prior art to help alleviate this problem. For example, forward error correction is noted in the art which adds data to a block or a predetermined amount of data being transmitted in order to be able to recover the data being transmitted. However, these systems are normally as good as the amount of redundant data stored and, thus, further slow down any systems as the amount of data increases.
Therefore, a problem in the art is that there is no method for delivering data at a high rate of speed to multiple units simultaneously, while still maintaining reliability the same or better of point-to-point communications.